home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19980901-19981211
/
000220_news@newsmaster….columbia.edu _Tue Oct 27 10:41:42 1998.msg
< prev
next >
Wrap
Internet Message Format
|
1998-12-10
|
5KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA11577
for <kermit.misc@watsun.cc.columbia.edu>; Tue, 27 Oct 1998 10:41:42 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id KAA07249
for kermit.misc@watsun; Tue, 27 Oct 1998 10:41:41 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Q. about running kermit over a proprietary transmission network
Date: 27 Oct 1998 15:41:38 GMT
Organization: Columbia University
Lines: 91
Message-ID: <714pji$b9b$1@apakabar.cc.columbia.edu>
References: <713hfu$3na$1@nnrp1.dejanews.com>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:9420
In article <713hfu$3na$1@nnrp1.dejanews.com>,
<tony_w_k_wu@my-dejanews.com> wrote:
: I want to run kermit over 57600 baud async. serial through a
: proprietary transmission system/network and comes out serially
: into another device. The typical transfer file size are
: about 300Kbyte. (up to 1 -2 Mbyte max)
:
: The proprietary transmission system is a CSMA/CD kind of LAN.
: Its speed is around 44Kbaud and it is NOT noisy.
: Note: the proprietary transmission system is about 10-20%
: slower than the serial link.
: It support :
: a) UNACK type of transmission of data packet with 88bytes data
: payload. (quick and no guarantee of delivery)
: latency is about 40 ms per 88bytes data packet.
:
: b) ACK type of transmission with segmentation/reassembly capability
: and arbitrary data length. (guarantee delivery)
:
: I need to build some software in the proprietary transmission system
: to convert the kermit over serial into
: either a) or b) type of transmission format. (or even combination of
: both)
:
: Note: there is no HW flow control ie RTS/CTS between the serial
: link
: Note: XON and XOFF is delivered transparently to the target device.
:
: Original thought is to build something extremely simple base on
: a) type of transmission.
: With a scheme like the follow:
: send a packet if I receive 88bytes serially or I have not
: send a packet in last 20ms and send whatever number of bytes
: I have received.
:
: Alternatively,
: I can look at the kermit initialization and negotiation sequence
: to figure out the packet length, window size. Look for the ^A and
: EOL to delimit each packet. And pack each kermit packet into
: type a) or type b) transmission adaptively. e.g. ACK/NAK kermit packet
: on type a) and data packet on type b).
:
: What do you think about the 2 schemes? Would I be able to gain any throughput
: improvement with the alternative scheme? How would you configure the window
: size and packet size in kermit to maximize throughput? Any thing I should
: take special care of when I am building something described above? Any other
: ideas to get the max througput?
:
You didn't say what the two end systems are. Let's assume they are two
computers capable of running relatively modern (i.e. tunable) Kermit versions.
Transmission type (a) is like an IP datagram; type (b) is like a TCP packet.
Kermit will work with either one, but if you want to use type (a) then, yes,
you should ensure that the Kermit packet fits in the 88-byte LAN packet.
This would, of course, result in rather slow transfers. You can improve the
efficiency by choosing a Kermit window size greater than 1 (whatever works
best, up to 31 or so). Kermit itself will handle resequencing, recovery of
lost packets, etc.
But unless there is some compelling reason not to use the guaranteed delivery
method (type (b) above), I would recommend that. In that case, you should
be free to set the packet and windows sizes to any combination at all that
gives good performance.
>From your description, it seems the most serious problem comes from lack
of flow control between the LAN and the computer. You say:
: Its speed is around 44Kbaud and it is NOT noisy.
: Note: the proprietary transmission system is about 10-20%
: slower than the serial link.
and:
: Note: there is no HW flow control ie RTS/CTS between the serial link
: Note: XON and XOFF is delivered transparently to the target device.
If this is true, then what prevents the computer from overrunning the LAN
when sending data into it? End-to-end flow control will not help very much
in this situation, since it is not the target system that is being overrun.
In the absence of effective flow control between the computer and the LAN,
the only ways to prevent data loss are:
1. Set the serial speed of the sending computer below that of the LAN,
and of the receiving computer *higher* than that of the LAN. This
is obviously inconvenient, but will allow the highest transfer rates.
2. Reduce the Kermit packet and/or window sizes to values that minimuze
overruns and maximize throughput.
- Frank